home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
JCSM Shareware Collection 1997 February
/
JCSM Shareware Collection February 1997 Best of (JCS Marketing)(February 1997).bin
/
PRGTOOLS
/
PREXCM60.ZIP
/
PROTEXCM.DOC
< prev
next >
Wrap
Text File
|
1996-08-17
|
23KB
|
601 lines
Protect! EXE/COM v6.0
Executable Encryption Package
(C) 1993-1996 Jeremy Lilley,
All Rights Reserved
August, 1996
Program Documentation
=====================
Contents:
---------
What's Protect! v6.0 ? ......................... 1
Requirements ................................... 2
How To Use Protect! EXE/COM .................... 3
The ProtExCm.INI File........................... 3
Which Files Can't Be Protected ................. 4
Legal Terms / Disclaimer ....................... 5
License ........................................ 6
Philosophy behind Protect! ..................... 6
Comments on Hacking Protect! ................... 7
Technical Notes ................................ 7
Compression Notes .............................. 8
What's The Mutation Engine? .................... 8
Closing ........................................10
Address ........................................10
What is Protect! EXE/COM v6.0 ?
-------------------------------
Protect! EXE/COM is an encryption and compression utility that
has been preventing modification, hacking, and reverse-engineering
in programs for the last three years. While the changes made to the
files are invisible to the end-user, Protect adds some powerful
features for program authors:
* Modification Check -- prevents a corrupted or hacked copy
of the file from running, giving your customized message to
the end user. View the modification message with ModMsg.EXE!
* File Serialization and Source Tracking - would you like to
know which copies pirated or hacked programs are coming from ?
With the SERIALIZE option, you can automatically embed an
encrypted number or string, to be displayed with the
modification message and viewed with ModMsg.EXE.
Page 2
* Anti-debugging Traps and a Custom Mutation Engine - make it
difficult to trace through Protected files or to for hackers
to write "auto-crack" files to target your programs.
* Differentiation in the Registered Code: The files produced
by the registered version are different from the unregistered
version to improve security of the registered version.
* Customizability - Now a number of options are available in
the ProtExCm.INI file to tune Protect better to your needs.
* Passwords - You can now optionally add a password to files
for extra security, and registered users can change the text
of the prompt.
* Executable Compression - Protect automatically attempts to
compress your files (unless disabled), but it also works great
with compressor programs such as PKLite (R) and LZEXE.
* Speed and Compatibility - Protect is written in heavily
optimized assembly language and has been tried and tested for
the last three years. Protect is tested from 8088 to Pentium,
under DOS, Windows (3.1, 95, NT), and OS/2.
The customizability options are the most new in Protect,
allowing various security features to be turned on and off.
Optional passwords and file serialization and tracking are also new
with this version, in addition to some security updates and minor
bug fixes.
Requirements
------------
Protect will run on just about any PC available today.
Protected files require about 1.8k more memory than their
unProtected counterparts, but, besides this, they should run the
same as normal, under DOS, Windows (3.1, 95, NT), and OS/2.
Page 3
How To Use Protect! EXE/COM
---------------------------
Much of the control for Protect! has been delegated to the
ProtExCm.INI file, but the command-line syntax for ProtExCm.INI is:
ProtExCm MyProg[.EXE/COM] Protexcm.INI
The filename must be a DOS EXE or COM file.
The ProtExCm.INI file (or the MyProg.INI, etc. file) holds
some setup information for Protect, with which you can use the
password, serialization, registered modification message, and
other features. If no INI file is specified, PROTEXCM.INI is used,
or if there is an INI file with the same file name as the EXE or
COM file, it will be used.
The capabilities previously available instead of the INI
file, which were turning off compression, and, for registered users,
customizing the modification message, have both been placed in the
ProtExCm.INI file (as "No Compress" and "CRC Message File").
Here is an example:
ProtExCm MyProg
(To Protect MyProg.EXE or MyProg.COM, using MyProg.INI
or ProtExCm.INI as the configuration file)
It is possible to apply Protect to a file multiple times, but
after too many layers, there will be noticeable loading delays and
perhaps errors.
For obvious reasons, no "unProtect" program is provided with
the Protect! package. A backup file with the ".OLD" extension will
be produced, however.
The ProtExCm.INI File (a.k.a. MyProg.INI or MyFile.INI...)
---------------------
This file, which must be in the current directory, lets you
specify defaults for Protect's behavior. The default, which
includes everything commented out, will work well in most cases,
but you may want to "tweak" things for your files.
If the file you are Protecting has a corresponding INI file,
Page 4
that file will be used in place of ProtExCm.INI. For example, when
Protecting MyProg.EXE, a MyProg.INI will be looked for, and so on.
The options are listed below:
No Compress : Protect normally attempts to compress files
before encrypting them. Use this if you would like to
disable compression, especially if you are already using
PKLite or LZEXE.
No UnAV : Since Protect is written to prevent disassembly,
sometimes anti-virus scanners confuse Protected programs
as being infected with a virus. Normally, Protect adds
code to minimize this. Use No UnAV to disable this.
Password : To require the user to enter a password to decrypt
and run the program, add a line saying "Password" to this
file and below this line, add the name of a file with the
text of the password. Only the first 50 bytes are read.
Serialize : To add a number or string of up to 50 characters
to be displayed when the file is modified, use this
option. Add "serialize" to ProtExCm.INI and the name of a
file containing the serial number below it (Protect will
create this file if necessary).
If the text in the serial number file is numeric, Protect
will increment that and use that number. You can view the
serial number with the ModMsg.EXE utility.
Registered-only options:
CRC Message File : You can customize the generic modification
message outputted when your file is modified using
this switch. Just put the name of a file (only 4k is
read) under this line to use.
No UnIntruder : There is a generic Borland C/Pascal hacking
program known as Intruder that Protect adds code to
specifically combat in the registered version. To disable
this unIntruder code, use this line.
Password Message : If you're using the password option above
and you want something different than "Password? " to
greet the user, use this line and put the name of a file
containing the prompt below it. Maximum 500 bytes.
No Jmute : USE THIS SPARINGLY. It disables Protect's custom
mutation engine as well as options like unIntruder and
unAV code.
Which Files Can't Be Protected
------------------------------
Protect! EXE/COM cannot Protect Windows and OS/2 EXE files
because the formats for these files are substantially different and
more complex than the regular DOS EXE format.
Page 5
For your information, a Windows EXE starts out looking (from
Protect's perspective) like a small DOS EXE that can only display a
message that "This file requires Windows." There is a pointer to a
Windows New EXE header, which Windows finds and uses as the Windows
file. I have written a freeware program called EXE-Combine that
exploits this and allows you to attach a DOS program to a Windows
program. Protect! will now automatically detect if a file is for
Windows or OS/2 so that you don't waste your time trying to Protect
them.
Also, due to the structure of Protect! and the DOS memory
model, files larger than the 600k neighborhood can't be Protected
(because the entire file has to be able to fit in memory all at once
when it loads). This fact, of course, makes Protect! worthless for
many xBase files where the basic "Hello World" EXE can be over a
meg. There is no compelling reason to Protect files like
COMMAND.COM.
Legal Terms / Disclaimer
------------------------
The only guarantee behind Protect! EXE/COM v6.0 ("Protect!")
is that it has the ability to alter EXE and COM ("executable")
files. Due to the extensive number of possible executable files and
variety of computer systems, it is impossible for the author
(Jeremy Lilley) to guarantee Protect. Protect! is provided "as is,"
and, as the user, you have been warned that using Protect! implies
that you understand that compatibility and other problems may
potentially arise. You, as the user, are responsible for any damage
caused by using or misusing Protect!, and under no circumstances
may the author be held liable for loss of profits or any other
damages arising from Protect. Also, it is your responsibility to
use Protect! only in a lawful manner.
Risk of incompatibility and damage resulting from Protect! is
actually quite small -- I have optimized for maximum compatibility
in creating Protect and taken many precautions. However, if you try
to make it mess up, it probably will. Just remember that it isn't
my fault if you misuse my program.
Also, all trademarks used are acknowledged to be property of
their respective owners.
Page 6
License
-------
You may use Protect! EXE/COM for the purposes of evaluating it
(after understanding the disclaimer and the documentation) for 30
days. No files protected by Protect! during this trial period may
be distributed to other users, commercially or non-commercially. If
you find Protect! to be of use to you, you must register Protect!
with the author, which is $25.
Sysops, user groups, disk vendors, CD-ROM vendors and other
similar organizations may distribute Protect! provided that no
files are excluded from the distribution and that no more than $10
(except for CD-ROM) is charged for distribution. Protect! may not
be bundled with any commercial product without prior consent.
Much of Protect!'s protection and encryption capability comes
from its anti-debugging and anti-hacking code. In order to keep
loading time to a minimum (yes, 1000-bit decryption keys *do* take
a while to process), the encryption key length is very little
(some advanced math with 32-bit numbers) compared to the encryption
keys regulated for export from the US. In addition, since the
decryption mechanism is and needs to be located on the file, the
Protected files themselves are not subject to export restrictions,
except for nations that the U.S. has normal trade restrictions with.
Philosophy behind Protect!
--------------------------
Protect! started to fill a void a few years ago when there
were few EXE or COM utilities that could not be easily hacked
through. Even the PKLite program wasn't safe. While the first
versions of Protect! were rather inadequate for this void, Protect!
has been built up as a solid encryption program.
While maximum security is part of the core ideal for Protect,
the most important factor is maximum compatibility. If a Protected
file can't run on the same target systems as its unProtected
counterpart, it would be rather useless. While this commitment to
making sure that Protect! runs under DOS-compatible operating
systems (DOS, Windows, Windows 95, Windows NT, OS/2) means that not
every anti-debugging technique can be used, it is much better this
way. This version, however, adds some flexibility with the
ProtExCm.INI file, so you can balance between security and speed.
I won't critique other file encryption utilities, but I think
it is important to note that many other utilities either do not
implement the same level of security or employ some questionable
techniques to attain their level of security. Protect! is designed
to be as flexible and powerful as possible without sacrificing
compatibility. What's more, the registered version is different
Page 7
enough that in the event that an unregistered crack is produced, it
should not work with the registered code.
Comments on Hacking Protect!
----------------------------
You may have seen master unProtect programs for old versions
of Protect. This, fortunately, is not the reason for this new
release (the registered version has stayed secure, which is where
my priority is). There have also been a number of people who have
plugged away at PROTEXCM.EXE long enough so that they can remove
the shell and change the message. With enough resources, breaking
through one specific file will be possible with any software-based
protection scheme.
While Protect! v6.0 is not `hack-proof,' no program of its
nature can be. It does put together a very tough combination of
traps and encryption that very few people will be able to break. I
have tried to make Protect! v6.0 the most secure, least intrusive,
and most stable utility of its kind, and I think it comes close to
its goals.
Technical Notes
---------------
First of all, thank you to everyone who contributed ideas for
this version of Protect. A special thank you goes to John Meyers
for his help with combating the `Intruder' program when I had no
time to write a fix last term. A thank you also goes to Nathanael
Weiss for encouraging me and constantly reminding me Who is utimately
more important than any encryption program. Also, thank you to those
who have beta-tested Protect, sent bug and virus reports, and passed
Protect! to others.
Most of the changes to this version have been less major
compared to previous releases, but there were many fixes and
additions that I wanted to release publicly. There are a few
techniques such as pre-fetch queue traps (trying to write to a
memory location stored in a processor's instruction pre-fetch area,
which kills debuggers) and using 386 debugging registers to kill
debuggers like Soft-ICE that I have not used because they are
incompatible with some systems (like OS/2 -- which really helped in
writing Protect). I also found out that Windows (3.x, 95, NT) does
not work well with self-tracing (Int 1) code.
Protect! v6.0 add a bit more than 1k to a file with an
average-sized modification error message, but it normally also
Page 8
compresses. The mutation engine can vary the size somewhat, and
Protect! will usually be able to take a few hundred bytes from the
file header on EXE's. The encryption technique involves large
multiplication of the numbers by changing keys, not XOR. The
compression is a simple derivative of the Lempel-Ziv algorithm, but
it is nothing compared to the complexity of the compression used in
PKLite. You may layer multiple copies of Protect! on top of each
other, but that will start to cause noticeable delays in loading.
Protect! written entirely in assembly language (try writing a
mutation engine in a high level language!), mostly with the A86
assembler. My main machine for Protect! now is a Pentium 150,
running OS/2 for development and Windows 95 for applications. If
you have any suggestions, questions, comments, etc. about Protect!,
you can easily contact me through email, or if nothing else, postal
"snail mail" and I am usually pretty open to your comments.
Compression Notes
-----------------
By default, Protect! tries to compress files before encrypting
them for both better security and smaller file sizes. Its algorithm
is derived from Lempel-Ziv, and it will go a long way toward
reducing redundancy in the underlying code.
Other compression programs like LZEXE or PKLite will in many
cases work better than Protect's native compression. If you have a
particularly large file or "too many relocation pointers" error
messages, I recommend trying an external compressor. There is a
small security trade-off to having another (known) compressor
underneath Protect, but for the most part, compression will help
with the resulting file
You can opt not try attempt to compress a specific file by
putting a "-N" at the end of the command line or the NoCompress
option in the ProtExCm.INI file. You can save some time if you've
used another compressor already and know that it won't compress
under Protect. It also might be wise to do this if there is a
noticeable loading delay caused by Protect.
What's The Mutation Engine?
---------------------------
A portion of Protect! EXE/COM that is largely responsible for
keeping people from making master "auto-crack" unProtect programs
is the "mutation engine." It is basically the "front door" that
Page 9
keeps unProtects out.
Many utilities that can attach an envelope on an EXE (such
as LZEXE or other file compression utilities) are the same every
time. That is why UNLZEXE or generic unprotect-type utilities are
relatively easy to make. When an unprotection utility (such as UNP)
unprotects a file, it creates a virtual-DOS environment for the
file to run in until the file finishes decrypting itself. When it
is done decrypting itself, the unprotect utility simply writes
what's in memory to disk and you have your unprotected file. The
program may use a different key every time and even encrypt itself,
but all the unprotect program has to do is just trace through that
until it gets to the original entry point, and it's written to disk
(plus some un-relocations and overhead, but.)
One of the tricks for foiling unprotection utilities and
debuggers lies is the fact that the unprotector must always have
control over the Protected program in order to stop it when it is
decrypted in memory. If you remove the unprotector's control and
subvert it without harming the operating system or other
concurrently-running applications, you are one step ahead in
protecting your programs. However, an unprotect program author can
just instruct his utility to detect the type of file and blank out
the bytes that would kill it when it gets to them. This would
result into a high-tech cat-and-mouse game.
The reason that it isn't too difficult to make normal
unprotects stems from the fact that the protector's security
envelope is the *same every time*. I coded a mutation engine for
Protect! to make sure that the security envelopes wouldn't be the
same every single time a new one is encoded. Instead of being able
to "trace in" a definite number of bytes every time and being able
to blank out a certain number of bytes every time, these figures
will have to vary between each and every different file that is
Protected. If you get one original file and Protect on several
different occasions, it will never be the same length or have the
same content every time (there are thousands and thousands of
different combinations). My mutation engine randomly decides which
machine code instructions to use every time: it may use a 3 or 4
byte equivalent of a 2 byte instruction or vice-versa in any order
that works. Because there are definite rules for this mutation, it
will work every time. Since the mutated portion is relatively small
(but effective), an extra byte or two in a spot will not adversely
affect the performance of your Protected files. Garbage code and
other distractions make it even more difficult for a hacker to
write a master unProtect. Protect! uses both a mutation engine and
a variety of anti-debug tricks interspersed throughout to help
attain maximum security for your files.
Page 10
Closing
-------
Protect! EXE/COM can save you time, effort, energy, and money
in securing your files. There are no run-time fees or royalties for
Protect! EXE/COM; one $25 license is all that is required for
commercial use of Protect and distribution of Protected files. The
registered version will allow you to specify your own modification
error messages, change the password prompt, and it comes without
the "beg screen."
There is a definite threat of hackers and viruses on the loose
and it is your responsibility to protect your programs. Powerful
encryption, passwords prompting, serialization, and anti-debugging
help provide protection to your programs as they go into the real
world.
Thank you for evaluating Protect! EXE/COM!
Address
-------
Jeremy Lilley
Protect! EXE/COM
2711 Oak View Circle
Medford, Oregon 97504
Email: jjlilley@mit.edu * CompuServe: 75060,2074
URL: http://web.mit.edu/jjlilley/www/protect.html